is there a way to control which job to start, instead of all of them ? good for local testing purposes
With the JobFactory you could control that by commenting out the specif job you didn't want

The best would be to control the jobs from the config. For example, with isActive flag.
As for the JobFactory, with the current change, you can comment lines related to a particular JobConfig and achieve the same result. But of course, it's not how it should be in the first place. Config or env variables is the way to go.

  // {
  //   jobKey: "validity",
  //   defaultFrequency: Constants.VALIDITY_CRON,
  //   jobFunction: validityJobWithTiming,
  //   name: JobNames.Validity,
  // },
  {
    jobKey: "score",
    defaultFrequency: Constants.SCORE_CRON,
    jobFunction: scoreJobWithTiming,
    name: JobNames.Score,
  },

why Not Running starts with capital letters ?
They should probably be constants/enum defined somewhere rather than hardcoded strings, wdyt ?

100% agree, that's the plan.
I commented, There is a dependency on status names in scorekeeper-status-ui. I decided not to touch it just to minimize the impact of the current PR. Also, I need to check if more dependencies on this status name exist.

this should be of type StatusName, right ? can we avoid to have the string Not Running hardcoded ?

I partially answered in the previous comment. Please let me know if you want me to include this in the current PR.
For the renaming issue, there is a dependency at least on scorekeeper-status-ui.
For the hardcoding issue, it's easier, but the plan was to tackle it together.

does it make sense to have these jobKeys defined as constants or enums instead of hardcoded strings ?

Yes, it absolutely makes sense. This question also related to the default cron strings, which are located in the constants.

Current state:

• Config holds information about both job keys and cron strings.
• Source code also holds information about the job keys and default cron strings. The source code assumes the config could be not valid or not full.

The question is - why do we have defaults for the cron strings? If we trust the config, then we should have only one source of truth.

I suggest:

• Add an Enum containing all of the Job names (jobKey). It would be our source of truth.
• Validate the config structure (contains all jobs keys, cron string, isActive flag, etc.).
• Remove default cron strings from the source code.

This way we'd also simplify JobConfig type.

Instead of this👇 we'd need only mapping between jobKey and jobFunction:

  {
    jobKey: "activeValidator",
    defaultFrequency: Constants.ACTIVE_VALIDATOR_CRON,
    jobFunction: activeValidatorJobWithTiming,
    name: JobNames.ActiveValidator,
  },

Alternatively, we can leave default cron strings at the source code level. But store them closer to the Enum of job names or even in the same structure.

WDYT?

So, the idea is to nuke everything related to the Microservice version, right ?

Yes, but the idea of decoupling from the Gateway is still relevant. Implementing with bullmq is one option. BTW even with the queue implementation, I see no usage for that class. All the jobs would be initialized on the worker side and the worker becomes the new Scorekeeper in that case.

However, a simpler approach would be to leave everything as is and only change the job status handling. By persisting the job status in the DB and removing events, we can achieve similar results and decouple Scorekeeper from API. That's what I suggest.

Moving from this:
await createServer(config, handler, scorekeeper);
To this:
await createServer(config, handler);

This way API could get the job statuses directly from the DB and there would be no need to run everything tightly coupled.